This invention relates to digital telecommunication employing links among at least three nodes. More particularly, the invention relates to service flow establishment over a relayed connection.
In a digital communication environment, in order for two peer nodes to establish communication between each other in a form that complies with certain Quality of Service parameters, for example bits per seconds and max latency, a service flow must be established. A service flow is a transport service that provides unidirectional or bidirectional transport of packets from one node to another in the telecommunication environment. A service flow is associated with Quality of Service parameters for the packets that are transmitted via the connection. When the two peer nodes are hidden from one another, it is impossible to establish a service flow directly between the two peer nodes and so there is a need for one or more relay nodes along a route between the two peer nodes, with service flows to be established between each two nodes along the route. Tunneled service flow comprises a set of service flows that are established between two hidden peer nodes via relay nodes to implement one logical service flow between the two hidden peer nodes. For example a tunneled service flow between peer node-A to peer node-B via relay nodes R1, R2 and R3 comprise a service flow from node-A to relay node R1, a service flow from relay node R2 to relay node R3 and a service flow from relay node R3 to peer node-B. The service flows that implement the tunneled service flow must comply with the Quality of Service parameters of the tunneled service flow. A route is defined as a list of identification numbers, each number associated with a node, defining the order by which nodes are connected to each other starting with a first peer node, ending with a second peer node and including relay nodes intermediating between the first and the second peer nodes. As explained hereinafter this invention provides a mechanism for establishing a tunneled service flow between two hidden peer nodes, i.e., service flows that are established between two hidden peer nodes via a route of relay nodes to implement one logical service flow between the two hidden peer nodes, particularly in a shared media environment.
Prior mechanisms for establishing service flows include those described in the standard promulgated as IEEE P1901. This standard defines high speed (>200 Mbps at the physical layer) communication devices via alternating current electric power lines, so called Broadband over 8 Power Line (BPL) devices. In this standard it is proposed the problem be solved in the following way:
Connections between two nodes that cannot communicate directly are set up by successively establishing a connection for each link in the route between the nodes. Referring to FIG. 5, a tunnel is requested by the initiating node by transmitting a CM_MH_CONN_NEW.request frame 1 to the first node in the route toward the original destination node (“Ultimate Destination”) via a series of intermediate nodes, starting with node R1. If accepted at R1, it and each successive node R2 in the route transmits a CM_MH_CONN_NEW.request frame 2, 3 to the next node in the route until the original destination node (“Ultimate Destination”) is reached. Each of these management messages contain a Connection ID (CID) chosen by the transmitter for the individual hop, as well as a Multi-hop CID chosen by the original source node that remains constant over all hops.
If the connection is accepted by the original destination node, the original destination node responds with a CM_MH_CONN_NEW.confirm frame 4 with the result code set to success to the node that sent the CM_MH_CONN_NEW.request frame. If the connection is rejected by any node along the route, such as node R2, then the node (R2) is set to respond with a CM_MH_CONN_NEW.confirm frame 3, but with the result code set to indicate the reason for the failure to the node that sent the CM_MH_CONN_NEW.request frame. In this case, there is no contact with the original destination.
Upon receiving a CM_MH_CONN_NEW.confirm frame, a STA along the route is set to transmit a CM_MH_CONN_NEW.confirm frame with the result code set to the same value received in the CM_MH_CONN_NEW.confirm frame to the STA that originally sent the CM_MH_CONN_NEW.request frame (frames 7 and 10 in FIG. 5). Thus, success or failure is propagated back towards the originating node. If global link IDs are not requested, then the path is set up once the originating node has received its confirmation. If the initiating message indicates that global links are desired, then each STA that receives a CM_MH_CONN_NEW.confirm frame with the result code set to success is set to transmit a CC_MH_LINK_NEW.request frame to the Domain Master DM (frames 5, 8, and 11 in FIG. 5), containing the CID and the MH_CID. If the Domain Master DM grants the Link, the Domain Master DM is set to transmit a CC_MH_LINK_NEW.confirm frame providing the GL identifiers (GLIDs) to each STA on the Link (frames 6, 9a, 9b, 12, 13a, and 13b in FIG. 5). The relay node does not send the CM_MH_CONN_NEW.confirm frame with the result code set to “success” to its predecessor in the path until it receives a success confirmation from the Domain Master DM. The Domain Master DM does not associate the individual GLIDs for each hop together using the MH_CID and OSTEI that is the same for all requests for the Multi-hop Connection being established. The Domain Master DM also does not transmit the CC_MH_LINK_NEW.confirm frame to the original source station nor to the original destination station until all of the Links in the route have been successfully established. Once the CC_MH_LINK_NEW.confirm frame is received from the Domain Master DM, the original source station and the original destination node may begin using the Connection.
If the Domain Master DM cannot set up all of the Links in the route due to insufficient bandwidth for example, then the Domain Master DM is set to transmit the CC_MH_LINK_NEW.confirm frame indicating failure for the requested link (frame 9a in FIG. 5) to the requesting node and the CC_LINK_REL.indication frame to all nodes with existing Links (known from the OSTEI and MH_CID, frame 9b in FIG. 5), and the node receiving the CC_MH_LINK_NEW.confirm frame indicating failure propagates a CC_MH_CONN_NEW.confirm frame indicating failure to its predecessor (frame 10 in FIG. 5). The DM need not transmit any frame to any node that has not yet received notice of global link establishment. These nodes will each receive a CM_MH_CONN_NEW.confirm frame indicating failure from their successor in the attempted connection path. The last node adjacent to the original destination is set to send it a CM_CONN_REL.indication frame. If a link is terminated for any reason, then the Domain Master DM is set to send the CC_LINK_REL.indication frame to both nodes on each link in the route indicating the Connection has failed (frame 9b in FIG. 6).
The prior solution to the method of tunnel establishment proposed in IEEE P1901 standard as described above is not efficient. The method for tunnel establishment as specified in IEEE P1901 is started by the originating node that establishes a connection to the first relay hop. Each relay node in the path towards the ultimate destination node establishes a connection to the next node. After all the connections are established in every hop along the path until the ultimate destination node, the last relay node in the path requests bandwidth resources from the domain master for its hop. If in the end of the process the Domain Master DM does not confirm the tunnel establishment, the whole protocol process has been executed for nothing, since all the participant nodes in the tunnel should be informed that they must delete the established service flows and all the involved nodes should release the allocated resources.